home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
programs
/
xrs510.zip
/
NEWIN510.DOC
< prev
next >
Wrap
Text File
|
1993-02-04
|
67KB
|
1,164 lines
XRS version 5.10 is a non-beta public release of XRS 5.04 "Wide Beta"
A *Special* note to long-time XRS users: (and v 5.0 "Mod 4"+ users!)
Even if you have stuck with "Page View" (scrolling screen-at-a-time)
message viewing since 'day 1', you likely want to try the new optimal
viewing mode again: multi-screen messages are now displayed with all
menubar options available at all times, etc. - see item #36 in the
section on changes from 5.00 -=> 5.01 below! Item #36 was greatly
enhanced for 5.01, even if you have XRS 5.0 with "Mod 4" or "Mod 5"
patches applied - read it again!
Fixes in 5.10, not found in 5.04 "Wide Beta":
1) XRS properly finds bbs_id_.ORG files in the current directory for a
specific BBS and 'locks' the origin lines for those conferences if you wish,
and it also doesn't screw up "RANDOM.ORG" for other areas if XRS.ORG is in
the current directory (and not on the PATH instead). 'bbs_id_' above must
match the name of the downloaded mailbag - exactly seven characters (pad it
with underscores to make seven characters if needed; i.e.: RHOUSE_.ORG).
Further, XRS.ORG being in the current directory actually sends the proper
chosen origin line for the area, instead of your default ORIGIN.XRS brag.
2) The "Alias is Name" (or "Name is Alias") parameter in CONFIG.XRS works.
Fair Warning: Is you turn this parameter on, and you're not using a 12-step
(or similar) BBS where you really do use your alias for your name, you are
likely going to really make your SysOp angry, possibly causing banishment
from the XRS system! BE CERTAIN YOU QUALIFY TO USE THIS - IT IS MEANT ONLY
TO ALLOW USERS OF BBSs THAT ALLOW USE OF AN ALIAS AS YOUR REAL NAME ON THE
BOARD TO USE XRS TO ENTER MESSAGES INTO "ALIAS ONLY" AREAS.
3) A low-memory data overwrite problem was detected in the startup routines
with "Bounds Checker" v2.0 and corrected. A total of four problems were
found in various portions of my code and the "HX" code under varying
conditions - probably been there 'forever'... [for examples, the first call
to "HX_Create()" would destroy interrupt vector 0 (division by zero) writing
over a NULL pointer, but since I never divide by zero, it didn't matter - I
now fix the interrupt vector immediately after it is mangled by the HX code.
4) Many of the C_Worthy 1.21"MYR" routines were recompiled with Borland C++
3.1 with full optimization, resulting in a slightly larger, but noticably
faster XRSCORE.DLL library.
5) "Allow HiASCII" works only on "Brag" lines, allowing you to enter them
in Chinese native language. This parameter is intended ONLY for usage with
the Taiwanese NLS support overlay available from Wen-Chung Wu. YOU SHOULD
NOT USE IT OTHERWISE! (Hi ASCII characters in English echomail well get you
a nastygram from the infamous "GMD" program.)
6) XRS no longer tests for Desqview when running under OS/2 (and therefore
no longer displays erroneous messages about "Desqview 3.0" when you are
running a program that tricks XRS into thinking DV is there, but is not).
7) Copyright notices updated to include 1993.
8) OS/2 2.x virtual UMA support for DOS is truly screwed up! I have reported
the problem(s) (which persist in the 2.1 beta) to IBM for repair: When UMBs
are turned on (in the dialog "DOS Settings" under the "General" tab), OS/2
will report 0 as the largest available block. When it is turned off, OS/2
will report a nonsense number, in my case 3072 (although no UMBs are
available). For the time being, XRS will report (unfortunate) reality as it
sees it: if UMA support is on, it reports "No UMB Provider", since it sees 0
as the largest available block - if UMA support is off, it will report "UMBs
Hosed" and disable UMB allocation, since OS/2 is reporting total UMA is less
then the largest UMB. For the time being, I've decided to bastardize my code
and try to correct the situation (when possible): if "Largest UMB = 0", I'll
try to allocate them anyway, and correct the value which is reported by OS/2
(if I can successfully allocate blocks). Sometimes I get away with it, most
of the times I don't - go figure - "don't ask me why, 'cause I dunno!". Oh,
well - when they fix it, it'll work <g>... Of course, this is only going to
affect you if you run XRS under OS/2 2.x! OS/2 1.x has UMA support disabled
since there is none provided in the "DOS Box" of OS/2 1.x versions.
9) XRS properly detects OS/2 2.x "VXMS" services, even though a query for the
"XMSXXXX0" device driver fails. (reported as "VXMS.Sys" just like QEMM, HiMem
or 386^Max - with version number)
10) XRInstal.Exe looks for "XRS510.ZIP", "XRS510XT.ZIP", "X386V510.ZIP" and
"XRCFG104.ZIP" instead of previous version filenames. If you need to install
any other version, use "XRINSTAL -F" to change the <F>ilenames.
11) XRS/386 only delays 1 1/2 seconds during the logo "rainbow/cascade". It
*is* <ESC>apable!
12) XRS *always* puts a ^aPID line into every message, regardless of the
setting of the "No Pids" parameter. Turning off No Pids simply adds the
old "--- XRS! 5.10+" (or similar) back to the tear line at the bottom. Due
to the truly screwed-up programs written by Gerard van der Land which
violate FTSC standards and remove and/or alter either or both, the ^aPID
line doesn't have a ":" after it any more, to attempt evasive action (so as
to avoid his programs ripping them out and replacing them with his own).
13) Ralf Brown's "SpawnO()" swapping utilites updated to version 4.13.
14) A new '386 version of XRNeedle ("XRNDL386.EXE") which handles up to 1/4
million messages in a single mailbag (with sufficient memory) is available
in a separate archive: "XRNDL386.ZIP". It is a 'flat 32-bit' DOS extender
protected mode version, which uses all available memory. (any XMS or 'raw'
INT15-accessible extended memory) Using DOS 32VM code, it takes less than
10 seconds to rethread a 15,000-message mailbag!
15) XRS 5.10 has been tested under OS/2 2.1/beta, MS/DOS 6.0/beta2, QEMM386
v 6.03 and QDPMI version 1.01 - all seem to be in working order mostly <g>...
See however the note about OS/2 2.x virtual UMA support - it's screwed for
now - as soon as it learns to play correctly, my code will work.
16) All versions of XRS are distributed with PKZip 2.0x compression, and
imbedded "-AV" (Authenticity Verification) which uses tighter compression
and a new more secure -AV code system, to prevent faking and hacking the
release files. Note that PKUnZip.Exe 1.xx users will not see -AV (nor will
they be able to extract any files from any of the archives, anyway) - "None
genuine without my signature...".
17) XRInstal.Exe should actually work without locking up at the end on '286
machines (or any machine without an XMS driver loaded). It also doesn't stop
and make note that you have a wierd "286" chip, either.
==== 5.10 non-beta watermark ====
18) A condition which would occasionally cause XRS to display a message that
should exactly fit into a single screen to 'blank out' was fixed.
19) PKZip 2.04e used to compress and for "Authenticy Verification".
20) The ability to hit '-' (for previous message) during a multi-screen
message using "Screen-at-a-Time" viewing works properly again. You can
hit 'S', '+', <ESC> or the 2nd letter on the bottom line to skip forward.
XRS version 5.04 is a "Wide Beta" public release of XRS 5.04/alpha6:
(for changes between versions 5.02 -> 5.03 and 5.01 -> 5.02, etc see below)
1) Borland C++ 3.1 compiler patches two and three applied. Who knows?
2) XRS no longer leaves "BATxMAIL.XRS" open if you <ALT_F10> exit from the
program (which caused 'Share' violations when I tried to reuse it at exit).
(Reported by Johnathan Hutchins numerous times, just couldn't find it...)
3) I changed the spelling of "Receipient" to "Recipient" (good eyes, Daan! -
I thought you were Dutch <g>...)
4) The special '386 version is under development - currently only available
to alpha test team members. It features true '386 code generation, smaller
(much!) compressed overlay (RESP_386.DLL) for a 64K disk space size saving.
Adding the true DOS/386 extender isn't going to be easy until Borland
'fesses up with a true 32-bit *.OBJ compiler, though... RESP_386.EXE
requires a minimum of 2MB memory with 1MB either EMS or XMS.
5) I had to change the <F3> to send "UserRequest" to <CTRL_F3>, because it
was screwing everything else that 'keyed' on <F3> before (like modify the
message subject/to/area/etc once written, etc). (per bonehead Mike)
6) A new CONFIG.XRS parameter "Show Gateways" forces XRS to display any
'secondary' origin lines it finds. If you want them to be quotable, you
must set the "Quote Kludges" option on as well. (per request - Rudi)
7) "XRInstal" v 1.0 compiled with "Builder" <tm> v 2.03 is included. This
should eliminate the problem(s) with '286 machines hanging near the end of
the install procedure.
8) Wierd message numbers displayed (especially if you were backing up) for
"XX of YY" (messages) in "To You" mode with "New Only" on fixed.
9) XRS checks for message marked for deletion even when a mailbag has been
completely read - however, you can never mark all messages and delete them
(and end up with an 'empty' mailbag - XRS won't let you do so...).
10) In the UCC/TELOS version (non-shareware), <F4> doesn't pop up the whole
mess (it's back like it was before - a shortened, select list of options).
11) The "Select Area" group names may optionally be sorted (by name instead
of in numeric order). To enable this option, put "AreaName Sort" in your
CONFIG.XRS file.
12) If the "New Only" filter is on, hitting <DEL> when any message area is
highlighted will require you to confirm marking all messages in that list
'read'. (i.e. remove them from the list of messages to be read) When the
"To You" filter is on, this only affects messages to you, otherwise, it is
designed to easily mark 'read' a group of messages you don't want to read.
As part of this, "auto-cycle" to the last remaining area no longer occurs
(XRS used to 'auto-cycle' if only one area was left, regardless of the way
you set the "Auto Cycle" parameter - now it doesn't, otherwise, you could
never mark the last area 'read' if you needed to!) By the way: unless you
have the "Auto Cycle" feature turned OFF, this won't be available...
13) XRS improperly deciding "=-=-=-=-=" in the middle of a message was the
end of a message was fixed (again) - reported by Rich Veraa.
14) "Universal" twitting wasn't working exactly as I planned - if the twit
was in the "To Name", you still saw the message, minus the line with his
name in it (reported by Jim Mork). In conjunction with this, I disabled
the 'proximity' twitting (only twit by "From Name" and not "To Name" nor
"Subject" fields) if you put "From Twit" in your CONFIG.XRS. Most people
preffered it the original way...
15) New XRCfg102.Zip adds "Show Gateways", "From Twit" and "AreaName Sort"
to options recognized and setable in the configuration utility.
16) XRS knows an 'i486SX' CPU when it sees one. Note: the 'relative power'
is computed using integer arithmetic, so it seems to be quite happy with
"DX2" (or "Overdrive") processors <grin>... (actually, XRS does absolutely
*no* floating point arithmetic - even fractional numbers displayed are
computed using integer algebraic formulas.) An i486/66DX2 rates 97.4!
17) In 5.04/a1 XRS would spend eternity looking for the first message or
display the whole BATxMAIL.XRS during "All Read" looking for the top of the
mailbag identifyer which was introduced in the bug-fix #13 above - fixed.
(It must have been there for a *long* time, just never uncovered until I did
the repair to #13 above correctly - I had an unsigned field in one module
that was an integer in another - guess it's time to break out "PC/Lint" again
- I *despise* that darn obnoxious nit-picking thing! <g>...)
18) If you export a message you are viewing (not one you wrote yourself...)
then invalid output device name doesn't cause a repetitive sequence of error
messages - one per line in the message - it 'escapes' at the first error.
19) XRS releases time-slices after each message is displayed and when waiting
for an input event under OS/2 2.0 or later (same as it does under DesqView).
Note that XRS is not 'fooled' by programs that cause XRS to think both OS/2
and DesqView are active - only OS/2 time-slicing is executed in this case.
20) XRS/386 no longer 'doubles' the prompt when you <F10> Shell-to-DOS the
second (or successive) time.
21) XRS 'weeds out' the string removing multiple spaces when displaying the
item (area #, name, etc) when confirming an area deletion if you hit <DEL>
while the message area selection pick-list is displayed. (i.e. it displays
Mark "002 XYZ 2 unread" 'read'? instead of "002 XYZ 2 unread"...)
22) XRS allows OS/2 2.x sessions to use Upper Memory Blocks as long as any
UMB provider is accessible. If the calls to "UMBTotal" and "UMBLargest" are
contrary (which I seem to see a lot!), then XRS will disable UMB functions.
XRS displays "UMB's hosed!" on the <F2> screen when it notes this condition.
23) Under the TELOS/UCC (non-shareware) version, the option <CTRL_F3> to
send a "User Request" is not displayed or active.
24) Under any system which doesn't have a "LOCAL" group which is remapped
to group 0, XRS doesn't create a 'Local' group 0 - one which allows users to
enter new messages into the (non-existant) local area.
25) The bug in RTLink+ 5.11/alpha3 which caused recent alpha XRS/386's to
lockup on the 2nd external program call (or shell-to-dos) was worked around.
Version 5.11/beta7 still elicits the same problem, although I have not been
able to narrow it down to a small enough example for them to diagnose.
26) XRS/386 will only be available direct from me and is protected by both a
different name CRC function, requiring an "XRS386.KEY" file be present to run
in 'registered' mode (this allows you to run both earlier XRS's and the '386
version without having to keep changing your keys back and forth), plus it
requires that your own personal data be added to the RESP_386.EXE program!
See registration form for updating to XRS/386 - which runs 15-20% faster, is
capable of handling larger mailbags, and is 'tighter' code, both in terms of
386-code generation and smaller 'footprint' (by 60K!) in disk file size and
will run 'TurboCached' in only 144K EMS and/or XMS (or combined) memory. A
fee of $15 plus your current registration key is required to update to '386.
Remember: XRS/386 requires a minimum of 2MB of memory and a '386, '486 or
Pentium(R) processor. It is capable of using up to 32MB memory, currently.
Note: XRS/386 is *NOT* shareware! It will not run AT ALL unless registered.
27) XRS is linked with RTLink+ 5.11/beta7 - not 5.11/alpha'x' - seems cured.
It seems as though they were *really* hosing memory allocations somewhere...
This version should eliminate several 'odd' lockups and crashes, as well as
any shell-to-dos multiple lockups after "Restart", etc.
28) A long-standing bug in CWorthy 2.11's "QuickSortList()" procedure was
identified and fixed. This error *really* screwed up memory allocation, and
was likely responsible for other memory problems/side-effects even when it
was successful... The symptom would be a lockup, QEMM exception or similar
when sorting any 'not normalized' mailindex. Sometimes you would get a "DOS
Critical Error" (bogus one, at that!), sometimes it would just hang. Jeez -
0 for 2 - seems like I'd learn to quit trusting stuff I didn't write <g>...
(reported repeatedly by David Dyer-Bennet & Daan van Rooijen - thanks guys!)
29) A long-standing bug causing potential memory allocation problems in the
"ClearSetBG()" routine was causing XRS to clear a non-existant area of the
screen - potentially locking up on SuperVGA (> 50x80 geometry) displays.
Well - three memory allocation potentially fatal bugs in a row - must be on
to something! This could well be the problem which caused DesqView to go
nuts when the protection level was "set up", since it would cause XRS to try
to write outside the program's assigned screen area before displaying each
message in the mailbag.
30) The "ColorCascade" of matching strings (and the flashing XRS logo) have
been adjusted for better (more certain non-repeting) color rainbows.
31) Under OS/2, XRS no longer "Pegs" when awaiting input strobing the mouse
and keyboard 2000+ times per second. I added code to low-level "INPUT.ASM",
"USER.C" and "QUEUE.C" modules of C_Worthy to call a time-slicing interrupt
any time no input is available (int 0x2f, AX = 0x1680). The giving away of
time-slices at other points in the program was removed under OS/2 (not under
DesqView!), since it provides true multitasking and leaving them in makes
XRS 'jerky'. (thanks, geoffrey!)
32) In addition to the above, a general "tick-watch" routine was installed
to smooth the execution of "Rainbow" background routines (both the cascade
of the "XRS" logo, and highlighted string matches in the message display)
are limited to one color-change per internal clock tick (approx. 18.2 times
per second). The code doesn't take enough room or time to affect slower
computers, but slows down newer model 486/50 & 66 models enough so that you
get the old familiar rainbow color cascade instead of psychedelic flashback.
To keep the "tick_tock()" routine from eating keystrokes (or making jerky
response), InputStatus() is checked before waiting each tick (1/18th sec.).
33) If you want XRS to automatically create threads (but not sort the mailbag
into subject order, which sometimes may cause the answer to appear before the
question if someone changes the reply to a lower-alphabetic subject), then
use "XRNeedle.Exe" instead of XRS-Sort/XRSrt286/XRSrt386 as your Preprocess.
Note that only rethreading (which forces creation of threads even if they do
not exist in the output from your mailbagger) does *not* require normalizing
the index each time it is read - which any XRS-Sort/286/386 use does require.
XRNeedle.Exe is capable of handling a mailbag of up to 7500 messages. If you
always live within this 7500-message limitation, switching from XRS*Sort.Exe
to XRNeedle.Exe will take slightly more time calling that specific program,
but overall load time (and reload time for each subsequently load of the same
mailbag) will be much faster since the index will already be normalized. The
XRNeedle.Exe program rethreads 6400 messages in 6.448 seconds on my machine,
but normalizing a 6400-message index file takes over 21 seconds (XRNeedle
displays time statistics down to 18.2 parts a second using integer algebra).
34) If you want "Home" to actually skip back to the top of the thread and on
to the next topic instead of just go back to the home message of the thread,
then "Home Next" in CONFIG.XRS will cause XRS to automatically do a "Next"
(or equivalent for your language) after going home to the top of the thread.
35) XRS now properly detects any currently available CPU type whether or not
a DPMI host is loaded (prior versions could only tell an i486 from an i386 if
a DPMI host was loaded).
---Wide Beta watermark--- (things not in /alpha1 through /alpha6)
36) If you have XRS in "List View", XRS no longer 'jitters' the screen, first
showing the message left-justified, then with the list scroll bar, then again
left-justified and finally one more time with the list scroll bar. Instead,
the message is displayed in "Page View" mode actually, since there is no
reason to put the scroll-bar on the left on a message that takes less than
one full screen to display. This basically means "List View" = "Optimal", so
the old "Page View" parameter is now ignored, and the cycle in the <F4> online
configuration window switches only between old-style "Page View" and "Optimal"
modes (and not to "List View").
37) "[A]gain" selected from the menu-bar now only clears the appropriate part
of the screen instead of all of it, giving a less jerky repeat view. This,
combined with the above item also makes the general display of messages much
quicker, since I don't have to allow for three different viewing 'modes'.
38) XRS arrbitrates between background "Color Cascade" of matching strings and
input (from keyboard or mouse) and always choses processing input over a color
change sequence, providing less jerky movement when using the mouse (and even
a little the keyboard arrows) if several strings are highlighted at one time
in a scrolling message (more than one screen-full).
39) XRS 5.04 "Wide Beta" is linked with RTLink+ 5.11 (not 5.11/beta'x').
40) XRS/386 doesn't play any music by default. If you want it to play charge
and all that jazz, put "Music" into your CONFIG.XRS file.
41) If XRS can tell, it displays the version number of your mouse driver in
the place on the <F2> screen where it used to put "Mouse? YES". Of course,
if you're using a non-Microsoft mouse, the number returned may be 'cheated'
by your mouse driver, reporting which level of the M/S version it supports.
42) By request from "Bob R." - XRS now allows a 12-step or similar BBS to use
your alias as your real name (or vice-versa if you will), doing so requires
you place a parameter in your CONFIG.XRS file "Alias is Name" (or "Name is
Alias" - they are synonyms). This will allow Bob R. to write a message in an
"Alias Required" area <g>...
XRS "Wide Beta" version 5.03 is mostly a 'fix' for a few problems in 5.02:
(for changes between versions 5.01 -> 5.02 and 5.0 -> 5.01 see below...)
1) It didn't always find every match doing "AutoTag/Match" or <F8> searches.
(Borland C++ 3.1 optimization bug - I didn't change anything from 4.5x to the
current version, but juggling the lines around seems to cure it...)
2) Changing your default origin line from the <F4> config window was fatal.
3) PKUnZip's "-AV" feature was hosed on one release archive by my using a
pre-release PKZip 1.93a on it accidentally. The 1.93a version doesn't know
anything about 1.1x versions' "-AV" functions (they will be different in the
PKZip 2.x series requiring you get your PKZip with "-AV" protection direct
from PKWare). The 1.93a version was released to ASP authors by Phil.
4) If you had "New Only" turned off the <J>ump list was *really* hosed!
5) The full version number including sub-version (i.e. ".a2" for alpha2) is
displayed in the tear line or ^aPID: line as well as in on-screen displays.
This also allows for a five-byte "patch area" so that the Chinese native
language version can show a proper designator (like "XRS 5.03Cxxxx").
6) The "<Ins>ert file" routine was not displaying the 'target' subdirectory
for you to pick a file from properly (if at all): one line of code that
hasn't changed in three years compiles to different assembler output under
Borland C++ 3.1 for some reason - not sure if it's an optimization error or
just a plain bug, but I changed the code to do it a different way, and
everything works just fine again. I also tweeked this routine so it doesn't
use an oversized, mostly blank pick-list if there are only a few filenames.
7) XRS doesn't truncate the version information at 25 characters (it can be
up to 35 characters including the leading "--- ").
8) The first 'page' of the <F2><F2> "HeapWalker" routine displays credits
for development tools used to create the current version of XRS, as well as
the internal revision number. The internal revision number consists of the
julian date plus make number - i.e. "92206.03" being the third time XRS was
compiled on July 26th, 1992. The 'background procedure' if any (timeclock,
editor status, etc) is disabled during this routine.
9) XRS enforces the "Filename" filter (no imbedded spaces, UPPERCASED as you
type it, etc) when you type in a subdirectory name (drive & path) to display
during "Import a File".
10) PKLite v 1.14 is used now, providing better encryption security. A new
message "Encryption CRC Invalid/Mismatch" displayed at startup means the
security envelope has been tampered with - get yourself a legitimate copy of
XRS! Please report *ANY* occurances of this specific failure to me. (I need
to know where you got the 'mishandled' copy!) Sorry, but the program will
refuse to run if this has happened - you must obtain a legitimate copy which
is original as obtained from me (and untampered with). Your license to use
XRS precludes dissassembly of the program in any way, please do not attempt
to disrupt the security functions and encryption of the program!
11) An all-new "XRInstal.Exe" program which I wrote "from scratch" (I did
cheat just a bit) replaces the cumbersome old 'Automated Install' program,
which was both clumsy and not designed well at all for a program which is
distributed by BBS! This new (small!) program is equally useful for both
long-time XRS fans and new user setups - it will upgrade an existing copy
without 'damaging' your existing CONFIG.XRS file. This program was created
with 'hyperkinetix' "Builder" v 2.03, which is a "Son-of-a-Batch" compiler.
Future versions may be distributed with compressed files in *.BCF format and
require XRInstal to unpack them! (of course, the BBS distribution will be in
.ZIP format with "XRINSTAL.EXE", "READ-ME!.1ST" and "XRSxxx.BCF" inside)
12) XRS properly detects and informs (on the <F2> info screen) the residence
of "HIMEM.SYS" as a '386 memory manager (and its version number) as well as
the new "QDPMI" DOS Protected Mode Interface host for QEMM.
13) XRS has been tested (no problems) under MS-DOS 6 level .015 alpha build.
14) A problem in the file look-up for last names (activated when you hit the
<INS> key after typing 2 to 6 characters of the last name at the "To Name:"
propmt) was fixed up. Sometimes it worked just fine, other times it would
'miss' certain names depending upon the filesize, etc.
15) Sending a "User Request" to turn a message area on or off, or to do file
downloads can be accomplished by hitting <F3> at the "To:" name prompt.
Checking for messages to "XRS" finds anything that starts with "XRS" in the
"To:" field, and truncates the name at that point.
16) A nit that caused QWK format mailbags to have a 'funny' header when you
hit <CTRL_F10> (to cause XRS to do a screen dump to $XRS$PRT.SCR) was fixed.
17) XRS has been tested on super high-res (1260x1024) monitors at up to 132
characters by 60 line and also at 100 characters by 75 line modes. Both are
perfectly readable!
=======
Changes from XRS v 5.01 -=> v 5.02 "Wide Beta"
* * * IMPORTANT * * *
* XRS 5.02's "286" version is now a true 80286-code program - it will no
* longer run on NEC V20/V30 chips! However, it is 10% faster still than
* previous versions on 80286 or higher computers. A DOS/386 version is
* under development that will be released for registered users only. When
* released, the archive will be XRS502^3.ZIP. As of this version of XRS,
* the '286 version is included in the 'standard' archive instead of the XT
* - which is in a separate XRS502XT.ZIP archive (opposite of previous
* verions). My reasoning is that 90% or more people use the '286 version
* anyway, and only the remaining 10% will need to get the other executable
* - instead of 90% wanting the '286 as well... XRS502.ZIP has the *286*
* executable only! - XRS502XT.ZIP is the generic. (of course - soon 50%
* of them will want the '386 version - I can't win!)
* * * * * * * * * * * *
(for changes between versions 5.00 and 5.01, see below...)
1) If you don't open any mailbag at all (go into "Write-Only" mode), then
"Buffer xxxx" space (which is used for BATxMAIL.XRS and you aren't opening
it) is freed - thereby increasing available UMB or 'low' RAM by up to 32K.
This occurs even if you don't change default 8K size with "Buffer xxxx".
2) You can customize your origin line for each message by selecting them
from a pick-list. If you want to activate this feature (otherwise, XRS
assigns a random one from "RANDOM.ORG" - which must exist to use this!)
put the "Custom Brags" parameter into your CONFIG.XRS user profile file.
Note that "Area-specific" origins override any random ones. When you <F3>
modify an existing message, if applicable - you can select a new brag.
When you use this function, XRS shows you the random origin line it picked
from your list (highlighted), and you are free to change it if you wish.
3) The SysOp can send an "XORIGINS.XRS" file which overrides specific
areas (only those he specifies) and locks those particular areas into a
certain brag/origin line. This way for special "alternate networks"
that have required text in the origin lines can be "fixed" and the user
can still either allow other areas to be randomly selected or picked
using #2 above. Note: areas specified in "XORIGINS.XRS" or "XRS.ORG"
(or 'bbs_id.ORG') are never prompted for random origins, since they
always use the area-specific one in those files instead. If an area in
XRS.ORG or 'bbs_id.ORG' duplicates one in XORIGINS.XRS, it is ignored
(and the SysOp-defined origin is used anyway).
4) The "XUC" program is only run for non-QWK (Fidonet) format mailbags.
5) XRS can 'capture' brag-lines from messages (for now, only 'perfect'
from Fido style, but with QWK format you have to edit a bit) and append
them to your RANDOM.ORG file - adding immediately to the available list
of random lines for "Custom Brags". To capture an origin line brag,
simply hit <ALT_S> ("steal") when a message is being displayed, and XRS
will pop up a confirmation window with the bragline ripped-off from the
current message (which can optionally be edited before saving). If you
do not want to add it, simply hit <ESC> to cancel the request. This
routine is actually available any time *except* in the internal editor
(where it does *not* work!) - so you can steal an origin line even if
you go do something else in-between (it always remembers the last one
it 'saw'...). If you don't already have a "RANDOM.ORG" file (and XRS
looks on the PATH for it if it's not in the current directory), XRS
will create one in the current directory, otherwise, the new brag is
appended to the existing file. Actually, you can use this to create
any origin line "on-the-fly" and add it to your RANDOM.ORG file, too.
(you might think of something 'bright' to put into a response when
you are just about to save it, for example...) Since XRS prompts for
the custom brag line *after* prompting to save the message, it is the
last item you get asked, and therefore you can add a new origin line -
even a custom one (just use <ALT_S> and then hit <INS> to clear the
captured origin line and type in whatever you want and hit <ENTER>).
6) You can customize the "QWK brag_ID can" which identifies 'extra'
origin lines and is used by the 'Nuke Garbage' filter routine by
specifying your own set of 'catch phrases' in "BRAG_ID.QWK". The
old internal set of rules is used of no external file exists:
"+++ " "-=- " ".ORIGIN: "
" * Via " "... " " ■ EZ "
" * EZ " "-- Via " "-> MegaMail "
" ■ SLMR " " * SLMR " " # GateOrigin"
" * DeLuxe" " . EZ " "+ Megamail "
This is a way to teach XRS's bragline ferret routine new QWK style
readers with non-standard origin lines (or what we would call origin
lines on the Fido side). Note that if you *do* build your own, you
should include all 15 strings above, too! (your BRAG_ID.QWK totally
overrides the internal table if it exists) This table can have at
most 50 entries - any additional ones are ignored. (one entry per
line - do not include the quote marks! i.e.:)
* Via
-- Via
-> MegaMail
+ Megamail
■ SLMR
* SLMR
* DeLuxe
7) I applied the second and third set of patches to my BC++ 3.0 compiler.
Heck - who knows? Could be good, could be bad! <grin>... Anyway - I
suppose "it's fixed!" in the BC++ 3.1 compiler, right? (yeah - right!)
8) The data memory utilization routine is enhanced to show both the true
data segment size (static data which isn't on the heap), and the actual
size of the HeapXpansion instead of just multiples of 16K LIM/EMS blocks.
(this is the 'hidden' "HeapWalker" function on the <F2><F2> hot-key)
9) In any mode except "All Read Sequentially", XRS would "lose its mind"
with mailbags containing > 3641 messages due to a pointer which "wrapped
around" at 64K instead of always remaining normalized in some cases. XRS
always created a proper > 64K block to contain the pointers (for mailbags
with more than 3641 messages) which were then loaded properly, but then
'traversing' the list failed when you hit element 3642 and everything
went downhill. XRS for DOS is now capable of reading a 100,000 message
mailbag (and still "Preload Summary" if you have 2MB of LIM/EMS memory).
Since I didn't want to say I had 'fixed it' unless I was sure, I created
a big-bad-mean-mother mailbag of 11582 messages and XRS choked it down,
had 1.2MB of total heap space (including 270K+ on the far heap, 120K in
UMB heap space and 800K in HeapXpander (LIM/EMS) memory). I did all the
nasty things one would try, like popping up jump lists, backtracking to
previous messages, writing replies, marking messages read from the <J>ump
list, exporting mail, hopping from message 11403 to 32 latterally, etc.
Couldn't seem to break it - the heap was still uncorrupted, the MAILxIDX
file was properly updated, and everything went just fine. XRSRT386.EXE
beat the mailbag into threaded/sorted order in just under one minute, and
required slightly under 900K of free memory to sort the list. Obviously,
a list of this size cannot be sorted using the standard or '286 XRS-Sort!
(Out of this 60 seconds, approximately 45 was doing file I/O, wherease the
11582-message sort only took about 15 seconds using the flat '386 model.
It takes slightly over 134 million compares to sort a list of that size!)
10) In working out the kinks above, I found I was doing a linear geometric
search to fix the end-of-message pointers when XRS*Sort is used, causing
XRS to search (total_messages ^ 2) items (i.e. 36 million checks for 6000
messages!). I rewrote the routine sorting the offsets first, then using a
binary search lookup, which is from 2500% to 55000% faster (or even more!)
depending on the number of messages (the more messages, the more noticable
the speed difference will be). (25x speed example is for a 250-message
mailbag, 350x speedup example is a 6000-message mailbag. A 10,000-message
mailbag would be 550x faster!) Loading sorted mailbag indexes (due to the
auto-linking of threads) and finding the true end-of-message pointers for
sorted mailbags takes much longer than for unsorted mailbags (the latter
step doesn't even have to be run), so I added a couple of tally counters
where the system appeared to "go dead", although it was working furiously.
Note that there is a point where you "hit the wall" when XRS can no longer
both load the MAILxIDX.XRS file into memory and "QuickSort()" the sorted
end-of-message pointers - at which point XRS has to drop back and punt and
use the old tried and true (but painfully slow!) routine instead. I was
easily able to QuickSort() a 6000-message mailbag, but the 11582-message
mailbag sent me out on a coffee break. I suspect the actual line is about
8000 messages or maybe slightly less (this assumes you have 50K of UMB's
free on a '386 machine, use DOS 5 with "DOS=HIGH" and have minimal impact
on your "low" [640K] memory usage). I recoded the original routine again
after I found out how huge the difference was, and improved the speed of
the routine by 25% by using "register" variables, too. (it is used seldom
now anyway - only if you gag XRS with a huge mailbag!)
11) If you had a mailbag with duplicate message numbers in different areas
and one of those areas was large enough to activate the "Virtual List"
feature of the message viewing <J>ump list, then XRS would refuse to 'back
up' any further than the first message # matching the lowest message # in
the area being viewed, and it would also refuse to advance any further
than the highest message # in the area (whether or not the message's group
matched the group #).
12) Sometimes "AutoTag/Match" and <F8> search/mark/tag didn't always find
every match. This was a bug apparently introduced in a recent version -
I didn't check to see exactly which revision it was when I screwed it up.
(it was *only* finding them if the first letter was capitalized!)
13) Since there was so much new code (all of which was overlay-able), I
increased the overlay cache buffer size to 160K (of LIM/EMS or XMS - if
you have it). I also split one overlay into two pieces, one of which is
seldom (if ever) called during a normal XRS session. This lets XRS still
run in the same memory required for previous versions even with all the
new functionality.
14) The <F3> (tag for export) and <DEL> (mark for deletion) in the <J>ump
list doesn't skip every other message if you hold it down (and associated
similar behavior related to the above is also corrected). Actually - if
you were reading normally (inside an area instead of "All Read...") these
toggles weren't working from the <J>ump list at all - although they *did*
display signals which made it *look* as if they were working (sometimes).
15) You must confirm your choice when you select "Delete All" (mailbag).
Selecting either "No" or hitting <ESC> from the confirmation window will
return you to the "Empty mailbag" option menu to make another selection.
16) Overlay structure was hand-balanced again, for smoother operation.
17) This version is linked with the latest RTLink+ v 5.02 update. For
those of you that have been running any 5.0x version (at all - even the
5.02/alpha1), please do not inform your old XRS that it doesn't work!
(RTLink+ 5.02 was put out to add BC++ 3.0 compatibility?!?) If you have
problems with XRS -vs- either EMS or XMS memory, you may need to disable
the RTLink+ caching overlays *before* you start the program (if so, the
program should tell you how to do so, and exit 'gracefully'). This will
only happen if there is a problem with your implementation of EMS or XMS
memory. Specifically, if you think you are having XMS memory problems
preventing XRS from starting - "SET RTOVEXT=0" before you run the program.
Similarly, if you are having problems possibly related to EMS memory,
"SET RTOVEXP=0" before you run XRS. Under normal circumstances, neither
of these settings is needed, but if you use them, they force the RTLink+
overlay caching code to skip EMS and/or XMS memory testing altogether.
18) A "strcat()" function where there "strcpy()" should have been used
was responsible for XRS occasionally hanging on startup. For some reason
this was only triggered (apparently) when the RESP_*.EXE file was not in
the current directory when you started (and even then - it depended on
what was in memory before-hand...). It looks like it was clobbering the
open files immediately after the storage for the string. Stranger still,
in the "TELOS" (non-shareware for United Church of Canada) version the
exact opposite symptom occurred: XRS wouldn't start *if* the RESP*.EXE
was in the current directory!
19) TCXL 5.52 update 6 was installed, cleaning up some of the oddities in
the EMS & XMS memory query. This new version should also detect and use
Windows 3.x 386/enhanced mode's "Alternate Video Buffer" (similar to the
Desqview method of assigning an alternate area for direct screen I/O). A
corrupted _BX register in the Hercules support initialization was fixed.
20) The problem (which only occurred in 5.02/alpha1!) where XRS would go
nuts after trying to edit your main brag/origin line (selecting 'O' from
the <F4> hot-key pop-up configuration menu). Also, formerly - XRS would
save the brag/origin line even if you hit <ESC> here - it no longer does.
The same thing happened if you have an alpha copy of XRConfig.Exe and
popped it up over the <F4> hot-keyed configuration window - this new
completely graphical (both DOS and Windows) XRS configuration program is
almost ready to release, now that the "Zinc" Interface Library 3.0 has
been received. It's been completely redesigned from the ground up, and
has nothing but radio buttons for "multiple choice" items, check boxes
for "Yes/No" options and a set of string and/or size prompts only for
those fields which require a buffer size or file/path for example.
21) Fixed a couple of cosmetic (display and log) mess-ups when the "To:"
name was exactly 25 characters long. Packets were correctly formatted...
22) The space bar during Optimized Viewing of multiple screen messages
scrolls the same number of lines as <PAGE_DOWN> (instead of 1 less).
23) An OS/2 v 2.0-specific Icon is included (XRS51OS2.ICO).
24) Since I found (and fixed) the problem which caused XRS to reload with
really wierd DOS version numbers (which if > 9 make it *look* like you
are using a "DOS Box" under OS/2), I added back the "OS/2" moniker to the
tear and ^aPID: lines.
25) After XRConfig is run from the <F4> hot-keyed configuration window
(by hitting <F4> again - XRS only offers - and allows - this if it sees
XRCONFIG.DAT and XRCONFIG.EXE in the directory or somewhere on your PATH)
XRS now properly resets the video screensize if you were in an 8x8 mode.
XRConfig 0.08/alpha was current as of this writing, and 0.50/beta should
be available coincidental with release of XRS 5.02! XRCFG050.ZIP will be
the filename - until superseeded by a later release. For now, XRConfig
will be separate from the regular release archive file, so it can be
easily replaced, but future versions of XRS will come with the current
XRConfig. (WinXRCfg, which is ready but I have no reason to release now
unless someone just wants it to play with it - is identical, as will be
future OS/2 PM and possibly *nix-flavored ("Open Windows" or more likely
"Motif") versions. XRConfig adds a whole new dimension to the world of
XRS - especially for new users! You can now easily install and configure
XRS without ever having to consult a manual, since XRConfig has built-in
detailed context-sensitive help for every option/parameter. With both
XRConfig and XRS's "AI" (Automated Installation) programs, new user setup
is easier and quicker than ever - and new users can be "up and running"
with an optimal configuration in no time!
26) Now linked with RTLink+ 5.10 (these guys are trying to keep up with
me <grin>...).
27) Compiled with Borland C++ 3.1 - here's to good luck! See note about
major change in the way distribution archive are put together up top...
28) More of the part of the program that is required to be memory-resident
during execution is bound into the "root" segment - the RESP*.EXE portion
as opposed to the RESP*.DLL part. This makes the XRSCORE.DLL significantly
smaller, and the root portion only slightly smaller. In the '386 version,
the RESP_386.DLL is small enough to only require 144K to cache overlays as
opposed to 160K required by both the '286 or "XT" versions. None of this
affects the run-time load size, just moves part of it and compressed more.
One of the most noticable side-effects of this change is that all versions
load (and reload) a little faster than before.
29) Since XRS knows that XRConfig is a road-hog (graphics-based programs
just are...) it always swaps out even if the "Swap" parameter is not on.
30) Having an XORIGIN.XRS file is not fatal (only happened in /alpha2).
=====
Changes from XRS v 5.00 (With no "Mods") -=> v 5.01 "Wide Beta"
┌───────────────────────────────────────────────────────────────────┐
│ These are listed in 'as-added' order - if you already have some │
│ or all of the 5 patch kits ("mods") applied to your copy, some │
│ of these may not really be "new" for you. The items toward the │
│ bottom of the list were added most recently, and each revision │
│ has a "waterline" marker between changes so you can easily tell │
│ which changes were applied at each mod level and also between │
│ XRS 5 "Mod 5" and this new "Wide Beta" 5.01 version. │
└───────────────────────────────────────────────────────────────────┘
==== (Start of 5.0 Mod 1 & 2 Level Changes) ====
1) XRS "bottom-line" time clock uses the native language format and date
separator properly (again).
2) XRS doesn't give a "Security Error '0xbad'" exit on non-80-column width
screens for unregistered users.
3) If XRS is allowed to "auto-size" in a non-standard mode, it doesn't
mistakenly assume that it's back in 25-line mode when it returns to the
"normal" font. For example, this would cause XRS to autosize from 37- or
40-line mode to 75-line mode and back to 37-line mode on my machine, but
place text and messages on exit as if the screen-size were 25 lines.
4) After entering the editor one time, hitting <ALT_F3> or <ALT_F5> when
no longer in the editor no longer causes bizarre results and/or hangs.
5) While in the "Color Palette" routine (via the <ALT_F7> hot-key) XRS
disables all interrupt function keys used by the internal text editor.
I also corrected the alignment of the color selection list for screens
wider than 80-columns.
6) The annoying 'flash-blink-flash' during "List View" display on slower
machines (when you <ESC> or <Enter> to the menubar) is mostly eliminated.
Also, the display of the "Saving Message Index" informational message is
before each message is displayed instead of afterwards, which contributed
added delay in the above sequence if you were using "Safe Mode".
7) The mouse cursor doesn't disappear (until you move the mouse or reset
it) immediately after a "Preprocess" routine is called. Also, after doing
an <F8> (or "Auto...) Match/Tag the mouse cursor returns immediately.
8) In the TELOS-specific version (non-shareware), <ESC>aping out of a pick
list of one element during area selection for message reading doesn't cause
a screwy "Auto Cycle" instead of just dropping back to the main menu.
9) <ESC>aping out of message creation after selecting an area which is
either private-only or lets you choose (and you chose private) does not
make the next message private regardless of area.
10) Someone noted that multiple substitutions of the same element into a
macro or attribution line didn't work. Well, I didn't intend for it to!
(since I couldn't think of any example where you would want to repeat the
same variable twice, but - I tossed in the code to handle it...)
11) Replies to messages for areas a user is not authorized to use (because
of security changes) are always marked private and put into the LOCAL area.
12) XRS doesn't display a phantom extra message at the end during "All Read
Chronological".
13) Fixed quoting (or export in quoted format) the last message. A related
bug - taking forever to find the end of the next-to-last message was fixed.
These both only occurred if you used XRS-SORT.EXE or any of its variants,
because the "end-of-message pointer" fix routine for 'abnormal' mail
indices was not taking the final element in the unsorted list into account.
14) Fixed a bug which caused XRS to stop reading messages during "All Read
Chronological" when it hits the last physical message in a mailbag. Again,
this only occured in sorted mailbags.
15) XRS doesn't "adjust" the SysOp-defined description for the first local
area used to be truncated to read only "LOCAL", and the forced remapping of
the first "local" group to group # 0 is gone. SysOps should be sure they
offer all users access to at least one local area where they can leave
private messages, so users without access to netmail can send messages to
the SysOp (and other users).
16) Fixed a bug which caused messages after being XRS-Sort'ed in "All Read
Chronological" to be displayed at random if no "ToYou" or "NewOnly" filter
was on.
17) "All Message Read (Chronological)" is now called "All Message Read
(Sequentially)" instead. This distinction is because the messages are no
longer chronological if they have been XRS-Sort'ed.
18) CONFIG.XRS allows you to "Hide Mouse" out of the default center of the
viewport, 'hiding' it in the lower right-hand corner instead. Note that
this will cause the mouse cursor to seemingly disappear until you move it.
(and will do so each time the mouse is re-initialized, like when you exit
from the <F10> DOS shell - until you move it again)
19) The "DOS Critical Error Handler" has been enhanced to make it a little
more obvious and center the actual error message as interpreted from DOS -
flashing in a single-border window with the active "Abort, "Retry", "Fail",
"Ignore" selection in a double-bordered window. Note that during a DOS
critical error, no interrupt routines can be called, so the mouse is not
active at that point (if you have a mouse you must still select an option
with keyboard). To allow for screen resizing, the portals for both the
error message and "Abort, Retry, Ignore, Fail" windows must be built in
advance, and now will always appear on lines 6 and 12 of the display
regardless of screen-size. Also, the default is pre-selected as "Retry"
instead of "Abort". In this case (and in any DOS Critical Error Handler!)
"Abort" means just that - blow XRS out of the water without cleaning up!
20) XRS now accepts up to ten "Twit" phrases, which match the To:, From:
and Subject: lines using a "proximity" search, so if a twit keyword you
give is found anywhere in the three fields, the message will be twitted.
If you twit "Bill", for example, you twit all messages to or from anyone
named Bill, with a lastname containing "bill" plus any that happen to have
a subject that contains the letters 'bill' in order. If you use a complete
name, messages to or from that person (or with their name anywhere in the
subject) are skipped - if you use a topic, be sure it isn't too short and
likely to match a lot of names or other similar subjects.
==== (Start of 5.0 Mod 4 Level Changes) ==== ("Mod 3" was 'internal' only)
21) A new meta-symbol "%b" is available for macros and attribution lines
that uses the AREA: name - as opposed to '%a' which uses its description.
22) The first group marked local or starting with the word "Local" is the
one selected to remap mail for areas no longer available, or on boards
where the user does not have access to the mail normally, but it is found
outside the selected areas because the name matches exactly. Previously,
this was only the first group which started with the word "Local"...
23) "Read-Only" groups show on the message read area selection list. (but
you cannot enter a message)
24) "No Reply" areas are supported. These areas allow read access but no
quote or reply, and allow you to originate new messages as well. This is
not currently possible with output of any XRS door, but XRSDoor 2.06 will
support it if the SysOp choses to make the "Read-Only" bit mean "No Reply".
25) If you reply to a private message, the default is private again.
26) You can mark messages for deletion (actually done with "XRSlice.Exe").
The C_Worthy "MenuBar()" source-code was modified to allow the entries in
the menubar to appear one character closer together to make more room.
27) XRS recognizes two new BBS types: "TAG", and "MK".
28) Output to LPT2: or LPT3: also gets a "Form Feed" at end if enabled,
and exporting messages from the mail reading MenuBar to a printer other
than LPT1: is performed to the proper device instead of STDPRN (LPT1:).
Also, XRS checks the status of printer devices before attempting any I/O.
If the printer is unavailable, you will be told and your request ignored.
If it is offline or out of paper, you will be informed and then you can
cancel or retry the output.
29) The long-standing bug in the C_Worthy library (which still isn't fixed
in the 2.03 version!) which causes areas to appear marked that should not
(especially after you hit the bottom of the message and <PAGE_UP>, etc) is
finally found and fixed. This bug only affected the internal editor.
30) XRS highlights all displayed "kludge" lines in blue. Also, previously
if "^aEID:" or "^aMSGID:" lines were in the text, they were not displayed
(and now they are). The XRS-specific "FROM-ADDRESS:" kludge in netmail is
also highlighted in whatever you have set in the "In a message..." color.
31) XRS supports AREA: tags up to 60 bytes (per the coming FTS-0004.002)
and 40 bytes description for the "SysOp-defined description" for each
area. (the old limits were 37 and 32 bytes)
32) The "Search/Tag/Mark" routine doesn't leave an extra "x lines scanned"
off to the right side if/when you "Hide" the search.
33) If you want XRS not to turn on the "ToYou" filter automatically (and
therefore not show you messages to you first instead of in sequence), you
can put "ToYou Off" into CONFIG.XRS which causes XRS not to turn it on.
34) If you hit <F7> to Unmark (UnRead) All messages while the "To You"
filter is on, only messages that are to you are unmarked.
35) XRS offers the "Repack/Delete/Both/Neither" and other exit options if
you are using an external bundler.
36) Part of this was in v 5.0 "Mod 4", but has been enhanced for 5.01:
"List View" mode has undergone a major "overhaul". During message view
mode, the spacebar acts the same as "Page_Down", any non-scrolling key you
hit is considered to be a command key (such as "Next", "Quote", "Reply",
"Back", etc) and passed to the underlying menubar routine after terminating
message view mode. If the key you hit isn't a valid option for the
menubar, then you will get a beep - and need to select another (valid)
option (in other words, XRS makes no attempt to 'validate' the keystroke,
merely passing it to the "menubar" routine - this allows me to have foreign
native language support without needing to 'know' which keys are valid).
Also, in "List View" mode, a 'place-holder' appears onscreen to show if an
incomplete screen is displayed when you hit "PageDown". It shows you where
to start reading new material, just like in "Page View" mode. XRS builds a
'fake' menubar just like it would show for each particular message. This
currently only recognizes English "Capital" letters, i.e. 'A'..'Z' - if
someone will provide me with a proper subset of the high-ascii foreign NLS
characters in the IBM character set that are "Capital" letters, I'll put
them in the hit list for the foreign NLS users, just in case you're using
an "odd" (for English) hot-key (otherwise, the foreign Capital letter
won't be highlighted!). Note that the pseudo-menubar *is* "hot" but not
really "live" in the sense that you cannot move the highlighted selection
as you could with the left and right arrow keys if the message were less
than a single screen-full. This also means if you want to select an item
from it with the mouse, you must hit the right button first! (and then
click on the option with the left button...)
==== (Start of 5.0 Mod 5 Level Changes) ====
37) During Color Cascading of matched text on monochrome screens, the
color doesn't fade to black (and stay there).
==== (Start of 5.01 "Wide Beta" Changes) ====
Finally...
Michael Barnes' XUC ('eXpress Userlist Compiler') is fully supported!
38) Full support for the XUC format (normally "USERFILE.XUC") user name
list file is included. XRS searches USERLIST.XRS first, then the XUC
USERFILE.XUC (if it exists, or you may specify an alternative name with
path if needed - otherwise USERFILE.XUC should be in current directory)
followed by up to two user-specified "USERLIST xxxx" in 'FidoUser.Lst'
format files. To specify a different filename for the XUCList (if any)
use "XUCList Z:\PathName\FileName.Ext" in CONFIG.XRS - this file will
override USERFILE.XUC even if that file exists in the current directory!
If XRS finds multiple exact name matches in the XUC format user namelist
they will be displayed and you will have to select a destination address.
Also, if you place the new parameter "XUC" into your 'CONFIG.XRS' file,
XUC will be called immediately after a preprocess function is called.
This allows you to specify XRS*Sort as a preprocess for new mailbags,
and have XUC automatically accumulate all new names and addresses in
each new mailbag. Note that the "new" condition is just as before:
either a newly unpacked mailbag is opened, or "Force New" appears in
your 'CONFIG.XRS' file already.
39) XRS has a built-in auto-lookup for names (and address) which uses
both the existing (up to three) UserList.XRS format files plus the XUC
format file Michael Barnes designed. If XRS 'sees' "USERFILE.XUC" in
the current directory, it will automatically use it whether or not you
specify it, or you can name your XUCList in the CONFIG.XRS parm file:
"XUCList X:\SOMEPATH\XUC_FILE.NAM" (but XRS only reads one XUC format
userlist!). The order of search: USERLIST.XRS (if it exists), followed
by USERFILE.XUC (or whatever you specify for "XUCList") next, then up
to two optional files named in "UserList xxx" parameters (if any). The
auto-lookup search is triggered by typing from two to six characters of
the *LAST* name and hitting <INSERT>. Instead of clearing the name
field (which it still does if there is one or more than six letters!),
it creates a pick-list of names which match the two-to-six characters
you typed, and you may either select one (if so, be certain to pick the
one with the correct address if this is netmail, the address you pick
will be used automatically without prompting!) - or hit <ESC> to return
to the name entry prompt and try again. You should remember that using
this method causes XRS to search all files regardless of whether an
exact match is found or not (unlike the auto-address lookup), so if you
have two or more very large lists, XRS may take a moment to do a binary
search of all applicable files and present a list. Picking a name from
the list which results from the search both sends the message to that
receipient and also uses the netmail address picked (if you are sending
netmail) automatically without later prompting for an address. If no
pop up list appears after searching, (XRS goes back to the name prompt)
there were no matches found at all in any of the user namelist files.
The actual lookup is "hot" - meaning that if you type "RAT" and hit the
<INS> key, after the list pops up with your choices, hitting more keys
will narrow the search (i.e. typeing "LED" at this point would hilight
one of my addresses, because I'm the only one in the nodelist starting
with "RATLED"). This doesn't change the list content, but rather moves
the pointer in the list to best match what you type. The entries in a
name pick-list are marked as follows: "1" = Primary USERLIST.XRS file,
"2" = Secondary USERFILE.XUC, "3" = First user-specified UserList file
(from CONFIG.XRS) and "4" = Secondary user-specified UserList file. If
any user namelist file is > 30K the search is quickly narrowed using a
trisecting binary search and no more than 8% of the file is read total.
(which should result in excellent lookup response times even when all
four lists are searched!) You can then easily narrow the search by
typing one or several more characters until you find the correct name,
and then hit <ENTER> to complete the process. XRS uses a "caseless"
sort here, so 'homrighausen' doesn't show up somewhere before all the
'A' names, etc <grin>... (in other words, names are sorted caseless)
40) The "ColorList()" routine I customized from C_Worthy to handle the
visually scrolling list which now allows "hot" access to command keys
if you us "Optimized View" mode (try leaving out "Page View" even if
you have been using it since day 1!) now actually scrolls a full page
up or down instead of (x - 1) as before. (in other words, you don't
have to skip over the first line each time you page down - and if less
than a full new page is displayed, a visual marker as described above
in feature update #43 is on-screen to show which line you last read)
41) Color cascade shouldn't "stall" as often when there are many items
highlighted onscreen at one time. (like more than a dozen...).
42) Repacking a mailbag retains the original file's date & time stamp.
It will actually "Deja vu" the files, repacking them with the original
timestamp even if they have already been repacked with an intermediate
time somewhere along the way (if you reopen and repack an old mailbag
it will regain its original timestamp, for example).
43) Other C_Worthy-based programs seem to have settled on using the
(normally green) 'Help' palette for the bottom-line help. If you want
this instead of the 'Normal' palette put "Help Palette" in CONFIG.XRS.
44) Under OS/2 2.0, XRS recognizes and uses virtual EMS and/or XMS.
45) XRS doesn't leave little chunks of UMB's allocated sometimes.
46) You can <ESC>ape out of the <J>ump list to the previously viewed
message. This only works correctly if you immediately <ESC>ape after
popping up the <J>ump list before entering other positioning commands.
47) Messages marked for deletion are tagged with '≡' in <J>ump list.
48) You can mark/unmark messages for deletion using the <DEL> key in
the <J>ump list. When they are marked for deletion, they are marked
read - if they are unmarked for deletion, they are also unmarked read.
49) XRS now prompts you asking permission to call XRSlice to delete
all messages you marked for deletion (if any). This (along with the
three other new features above) allows you to use XRS as a database
type message system when used in conjunction with programs from Rudi
Kusters' "XCS" system of programs. The prompting for this occurs
immediately after prompting for permission to write messages tagged
for archive only if you have "Always" in your "CONFIG.XRS" file.
50) Another hand-optimization of the overlay structure leads to lower
run-time memory requirements than any previous 5.0x version, and also
makes some operations a little quicker.
51) Under OS/2, TCXL 5's "UMB" support seems to either be freakin' out,
or OS/2 is feeding it bad dope! (I get wierd things like "12K largest
block" but "4K total free" and can't allocate any UMBs) For the time
being, UMB support is disabled under OS/2.
52) Marking messages Read/Unread (or Tagged/Untagged for export, or
Marked/Unmarked for deletion) matches the message area as well as the
message number. This is not significant to most users - but QWK users
have multiple message areas (XRS supports 1024) with duplicate numbers
in each area allowed, unlike the "Hudson-style" message base XRSDoor
exports messages from (which like the underlying database doesn't have
duplicate message numbers at all). Under this condition (reading a
QWK format mailbag with multiple messages having the same message
number), XRS was picking the first "hit" on the message number to
toggle Read/Tagged/Delete on and off instead of continuing the search
until both message number and area matched.
53) I have documented cases of XRS losing it's mind as far as to what
version of DOS (or OS/2) it's running under when it has been restarted.
This is undoubtedly the result of Borland's C++ 3.0 "exec...()" bug I
have already reported (and they supposedly fixed...) before. I sent in
another 'bug bitch report' to Borland on CompuServe, but haven't heard
back yet. For the time being, I have to drop back to DOS if it (the
_osmajor._osminor setting) is really whacked - you can restart XRS
yourself with <F3> or <UP>. Sometimes even this is "fatal" and locks
up your machine - I'm afraid I really can't do a thing about it! This
is also the culprit in the few cases where XRS reported "DOS 3.0 or
higher required" on restart... I can sometimes tell when it's going to
happen before it happens, and if I'm certain re-executing XRS will
cause the problem, I don't offer to "Restart XRS?" at all for now.
54) XRS calls the DOS shell slightly differently when swap/spawning,
and also calls external programs slightly differently if there are no
parameters being passed when swapping is enabled. Hopefully this will
cure problems with wierd parameters and/or environments being "lost".
55) XRS allows for funky (and incorrect!) replacement DOS command
interpreters that do not delete all files with one or two characters
during a "DEL ??.MSG" call. (It does so by deleting "?.MSG", checking
for more messages and nuking them.) This should work in every case!
56) Ralf Brown issued a new version (4.1) of his "SpawnO()" swapping
routines. This fixes several things I have reported and had to work
around before: No "blown" environments any more, the "SET TEMP=" and
"SET TMP=" environment variables are not "burned in" (or rather out)
and in fact if you swap-to-disk (have either no or not enough EMS or
XMS memory), they are used instead of the drive in a "Swap X" parm.
You can even override "all the above" (for disk swapping) by using a
new "SET SWAPDIR=xxx" parameter - which may contain multiple drives
(listing multiple directories on the same drive doesn't make much
sense: if there's not enough space in one dir, there's not going to
be space in another on same drive!). Example: "SET SWAPDIR=F:\;C:."
will try the root of the F:\ drive first, and if not enough space is
available, will use the current directory on the C: drive instead.
Changes from original XRS v 5.01 -=> May 3rd, 1992 edition v 5.01
57) Under certain conditions, if you used the <ALT_F10> hot-key exit out
of XRS, it was possible XRS would forget to deallocate a set of several
UMB memory blocks on a '386 or higher processor (if you allow the UMB
support). This was rare, but could happen in several different places.
I now keep a doubly linked-list chain of UMB's allocated in memory and
purge any leftovers in the "exitproc()" routine properly - no matter if
you are in the editor (or wherever) and hot-key out with <ALT_F10>. I
walk the linked list and free anything that would previously have been
left "hanging" (until you rebooted). I added UMA block information to
the "HeapWalk" hidden routine which pops up if you hit <F2><F2> (since
it really is part of the heap!). Information on any HeapXpander memory
is also shown in the HeapWalk routine.
58) Ralf Brown fixed the "SpawnO()" swapping functions so that the _PSP
isn't destroyed during swapping. XRS can now safely restart any time
and no longer skews the _osversion.